Method and system for verification of remote party identification

ABSTRACT

A method for processing a transaction includes receiving validation requests, automatically initiating one or more callbacks to an authorized transactor, and validating one or responses from the authorized transactor. The automatic initiation is in response to the validation requests, and according to pre-selected authorized transactor information. The responses from the authorized transactor are in reply to the callbacks. The validation is based upon the pre-selected authorized transactor information.

RELATED APPLICATIONS

The present Application is a Divisional Application of U.S. patentapplication Ser. No. 10/463,633 filed on Jun. 17, 2003.

TECHNICAL FIELD

The present invention relates to methods and systems for transactionprocessing, and more particularly, to methods and systems fortransaction validation.

BACKGROUND

With the continued technological advancements in the fields ofcommunication and travel, the world is becoming “smaller and smaller”,and more and more transactions are remote transactions, i.e. between aproduct/service provider and a remote purchaser. Examples of suchtransactions may be the purchase of a product over the Internet, or thepurchase of a service over the telephone. In many instances the paymentsmay be made with a credit card, a debit card, a smart card, or any othertechnology which affords payment of such types. One of the mainproblems, for both the provider and the purchaser, is to authenticatethe identity of the remote purchaser, or alternatively, to validate thatthe purchaser has the authority to perform the requested transaction.

One of the common present day solutions for the validation of remoteidentification is for the provider to limit the transaction to thosepurchasers who specify a valid billing address. Alternatively, otherproviders will only allow transactions where the shipping address isidentical to the billing address.

These methods have serious limitations. In the most innocent situation,the purchase may be a gift to be sent to an address that is differentfrom that of the billing address. In a less innocent situation, theunauthorized purchaser may be aware of the appropriate billing addressassociated with the selected form of payment.

As a further limitation, in many cases, the allowable billing addressesare limited to those in a specific country. This is mostly due to theinability of the provider to verify foreign addresses. This scenariolimits the ability of the provider to service global trade.

Secured electronic payment processing such as that provided by SecuredSockets Layer technology has other limitations. It requires customers tobe registered with at least one certificate authority. It requirescomplex interaction between different certification authorities, whichmight use different technologies. It is also limited to electroniccommerce.

Another known validation approach is for a person representing theservice/product provider to phone the home of the credit cardholder, whois presumably the purchaser, and validate the transaction. The cost tothe provider for such an action is an obvious limitation. Additionally,even when such a validation method is used, chances are thecardholder/purchaser may be performing the transaction from a locationother than his home, and hence, the cardholder may not be found. Thefunctionality of such a solution is limited.

SUMMARY OF THE INVENTION

Accordingly, in light of the limitations of prior art validationapproaches, the present invention provides a transaction processingmethod and system that comprises an automated verification callbackmethod and system. The callback method, and associated response method,may be selected by the authorized transactor, and known only by himselfand a verification service. In alternative embodiments, the authorizedtransactor may have a verification password stored in an optionalpassword database.

The present invention may be applicable to any action initiated by aremote party, requires identity validation of that remote party.Consequently, one aspect of the present invention provides a method andsystem to verify that a transaction originator is an authorizedtransactor.

In addition to the examples listed in the Background, other transactionexamples may include service requests or request for access into asecured area, etc. The present invention may apply to any case where theprovider lacks or has limited information about the transactionoriginator, and would like to validate the transaction authority of thetransaction originator.

In accordance with an embodiment of the present invention, there istherefore provided a method for processing a transaction. The methodincludes receiving validation requests, automatically initiating one ormore callbacks to an authorized transactor, and validating based on oneor more responses from the authorized transactor.

The automatic initiation is in response to the validation requests, andaccording to pre-selected transaction information associated with theauthorized transactor. The responses from the authorized transactor arein reply to the callbacks. The validation is based upon the pre-selectedauthorized transactor information.

In another aspect of the present invention, the method further includesproviding a validation response relating to approval of the validationrequest, wherein the validation response is in response to thevalidation requests. The method may also include confirming a passwordassociated with the authorized transactor, wherein the pre-selectedauthorized transactor information includes the password.

In accordance with an alternative embodiment of the present invention,the present invention provides a transaction processing system includinga callback processor and a validation server. In response to one or morevalidation instructions received from the validation server, andaccording to the pre-selected authorized transactor information, thecallback processor automatically initiates one or more callbacks to theauthorized transactor. According to the pre-selected authorizedtransactor information, the validation server validates the contents ofone or more responses from the authorized transactor.

In another aspect of the present invention, the callback processorincludes an input/output (I/O) device, a callback interface, and acomputer processing unit (CPU). The I/O device receives the instructionsand then sends response information. The callback interface activates acallback in a specific method and may receive responses in the samemethod. The CPU activates and manages the processes of the callbackprocessor using callback management software.

In another aspect of the present invention, the validation serverincludes an input/output (I/O) device, a memory, and CPU. The I/O devicereceives one or more requests for validation, sends back validationresults, and sends the instructions to the callback processor. Thememory holds the pre-selected authorized transactor information. The CPUimplements validation processes management.

In some embodiments, the validation processes management are deployed bya computer software product. In other embodiments, the pre-selectedtransaction information includes a password. In yet other embodiments,the validation server includes the callback processor.

In accordance with an alternative embodiment of the present invention,the present invention provides a computer program embodied on acomputer-readable medium. The computer program includes a first segmentoperative to receive validation requests. The program also includes asecond segment, operative to automatically initiate, in response to thevalidation requests, according to pre-selected transaction informationassociated with an authorized transactor, one or more callbacks to theauthorized transactor. The program further includes a third segmentoperative to validate, according to the pre-selected authorizedtransactor information, one or more responses from the authorizedtransactor, i.e. the responses in reply to the callbacks.

In one aspect of the present invention, the program may also include afourth segment operative to provide a validation response relating toapproval of the validation request; the validation response in responseto the validation requests. In another aspect of the present invention,the program includes a fifth segment operative to confirm a passwordassociated with the authorized transactor, wherein the pre-selectedtransaction information includes the password.

In accordance with an alternative embodiment of the present invention,the present invention provides processing of a transaction; the methodincludes deployment of the computer program described above.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of example,with reference to the accompanying drawings, in which:

FIGS. 1A and 1B are general block diagrams illustrating a validationsystem and infrastructure, constructed and operated according to anembodiment of the present invention; and

FIG. 2 is a flowchart that details a verification method operatedaccording to an embodiment of the present invention; and

FIG. 3 is an illustration of a validation server and a callbackprocessor, constructed and operated according to an embodiment of thepresent invention.

DETAILED DESCRIPTION OF THE INVENTION

Reference is now made to FIGS. 1A, 1B, and 2, block diagramsillustrating verification system 10 and a flow chart illustrating oneoperative embodiment of present invention, respectively.

System 10 provides verification of remote transaction originator 12′.System 10 is an automated, customizable verification system that allowsfor user selected callback methods. System 10 enables verification thattransaction original 12′ is, or is not, an authorized transactor 12″.System 10 may comprise one or more optional password databases 18, oneor more validation servers 20, and one or more callback processors 22.

In a preferred embodiment of the present invention, a transactionoriginator 12′ may contact a transaction provider 14, initiating atransaction request, such as a service request or the purchase of aproduct. Transaction originator 12′ may communicate with transactionprovider 14 via various channels, such as a telephone call, a faxtransmission, an Internet site, an e-mail message, etc. Transactionprovider 14 may link or contact transaction approval authority 16.Transaction approval authority 16 may be the company responsible for thepayment method or the security system.

Transaction approval authority 16 may then deploy the services of system10, and more specifically, validation servers 20 and callback processors22. Validation server 20 may hold in memory pre-selected authorizedtransactor information, such as preferred authorization specifications,the pre-selected callback method, and a pre-selected response method.Alternatively, transaction approval authority 16 may choose to hold thepre-selected authorized transactor information, and thus instructvalidation server 20 to carry out and manage the validation process.

Validation server 20 may then contact a callback processor 22, which iscapable of carrying out the pre-selected callback method. Call backprocessor 22 then contacts authorized transactor 12″ via thepre-selected callback method. If authorized transactor 12″ istransaction originator 12′, or if authorized transactor 12″ authorizestransaction originator 12′ to perform the requested transaction,authorized transactor 12″ responds affirmatively to the callback.

In an optional embodiment, authorized transactor 12″ may issueauthorization with a password. The password may be held in the passworddatabase 18. If a password is used, either transaction approvalauthority 16 or validation server 20 may verify the password withpassword database 18.

When the response from authorized transactor 12″ is received, and thepassword is validated with password database 18, the transaction isapproved.

Upon failure to contact authorized transactor 12″, validation server 20may elect to reinitiate the process and/or choose an alternativepre-selected method of communication with authorized transactor 12″.

In a preferred embodiment of the present invention, system 10 and itsoperation may be fully automated, unless specifically requestedotherwise. As such, once transaction originator 12′ initiates atransaction, system 10 deploys an automated process in order to validatethe identity or authorization of transaction originator 12′. In apreferred embodiment, neither product provider 14 nor transactionapproval authority 16 need provide human interaction. A computerizedsystem initiates the callback process, sends the message using thepre-selected callback method and waits for the response via thepre-selected response method.

It is noted that while the above embodiment describes validation server20 and callback processors 22 as separate entities, in other preferredembodiments, validation server 20 and callback processors 22 may be thesame entity. As such, validation server 20 may provide the functions ofboth validation server 20 and callback processors 22.

It is apparent to those skilled in the art that elements of the presentinvention may be accomplished by a fully hard wired system, or by acombination of a hard wired and software system. As such, the functionsof validation server 20 and callback processors 22 may be implemented bydeploying a computer program stored on a computer readable medium, andthe functions of validation server 20 and callback processors 22 may bedeployed from one or more entities.

In alternative preferred embodiments of the present invention, such asthat illustrated in FIG. 1B, system 10 may comprise multiple validationservers 20 and callback processors 22. It is noted that while FIG. 1Bshows only a limited number of elements 12, 16, 20 and 22, it isunderstood that system 10 may operate with numerous authorizedtransactors 12″, transaction originators 12′, transaction providers 14and transaction approval authorities 16. Additionally, system 10 mayoperate with numerous password databases 18, validation servers 20 andcallback processors 22.

In some instances, the authorized transactor 12″ may be at a locationdistant from transaction approval authority 16. Subsequently,transaction approval authority 16 may contact the validation server 20closest to itself, or one with which it has a contract. In turn, thecontacted validation server 20 may activate and manage the callbackprocessor 22 closest to the authorized transactor 12″. This optionalembodiment may be viable for embodiments wherein the callback and/orresponse method entail, for example, phone calls, either land lined orcellular.

Alternatively, the selected callback and/or response method may be viathe Internet, such as either instant messaging or e-mail. Forembodiments such as these, the location of validation server 20 andcallback processor 22 may be less critical, and consequently, system 10may be operated with any of the validation servers 20 or callbackprocessors 22 that have the capacity to perform the selected callbackprocedure.

Reference is now made to FIG. 2, a flow chart illustrating a commonoperative example of the present invention. The operative example mayentail the purchase of a book over the Internet.

A customer (transaction originator 12′) may link (step 50) to anInternet site of a book seller (transaction provider 14). The customer(transaction original 12′) may initiate a purchase (step 52) of booksand pay with a credit card. The credit card information may be submitted(step 54) to the book seller's site (the site of transaction provider14) in a manner well known in the art. The book seller (transactionprovider 14) may then desire to verify the credit information, oralternatively, to verify the authority of the customer (transactionoriginator 12′) to perform the requested transaction. The book seller(transaction provider 14) may then request authorization (step 56) forthe purchase from the credit card company (transaction approvalauthority 16) via a secured link.

In most instances, the credit card company (transaction approvalauthority 16) will activate the authorization process, while in otherinstances, the book seller (transaction provider 14) may deploy system10 to perform the authorization process. It is noted that in somepreferred embodiments, a verification service provider may provide theverification process for either the book seller (transaction provider14) or the credit card company (transaction approval authority 16).

Based on the transaction information and the authorized transactorinformation held by the credit card company (transaction approvalauthority 16), contact on an optionally secure line is initiated (step58) to the validation server 20. The credit card company may either havea validation server 20 or may use the services of a provider ofvalidation server 20. In some embodiments, validation server 20 may holdin memory the authorized transactor information. Upon receipt of therequest from the credit card company, validation server 20 contacts thecredit card holder (authorized transactor 12″) (step 60) via theappropriate callback processor 22 using the pre-selected method, forexample, via an e-mail (initiate the callback).

The credit card holder (authorized transactor 12″) replies using thepre-selected response method, such as via e-mail, (respond to thecallback) (step 62), or is prompted for a pre-selected password.

In some embodiments, in order to avoid missing a valid transaction dueto non-contact with the credit card holder (authorized transactor 12″)alternative forms of callback may be selected and initiated (step 64).For example, if there is no response to the initial email callback, aSMS message may be sent to the PDA of the credit card holder (authorizedtransactor 12″). In still other embodiments, the selected callbackmethod may be different from the response method.

Upon receipt of the response from the credit card holder (authorizedtransactor 12″), validation server 20 authorizes (step 66) thetransaction, notifies the credit card company (transaction approvalauthority 16), which in turn authorizes the transaction to the bookseller (transaction provider 14).

The above example is meant to be illustrative of the operation of system10, while not limiting the complete options of operation. Other possibleoperations of system 10, such as service requests, access requests,etc., are included within the true scope of this invention. Other formsof communication paths, either in the form of callback, passwords, orresponses are also covered within the scope of the current invention.

Selection of a Callback Method and Password

In a preferred embodiment of the present invention, upon receipt of apayment card, credit card, smart card, or other card from thetransaction approval authority 16, or when registering with a securedatabase or facility, authorized transactor 12″ may select a callbackand response method, and optionally a password. As an example, thecallback method, response method and password may be selected eitherwhen receiving a credit card or when receiving a work badge to a securedfacility. This pre-selected information is then kept in memory either byapproval authority 16 or by the validation server 20. The approvalauthority 16 may select to enable authorized transactor 12″ to modifythis information when needed. In both cases, it is the responsibility ofapproval authority 16 to verify the identity of authorized transactor12″ using appropriated means.

The callback method might be any of the following (but not limited to):phone call, fax transmission, e-mail, instant message, SMS to a cellphone, connection to a special application on a computer or a PDA,overland mail, or personal validation. Alternatively, the callbackitself may be a different method from the response from authorizedtransactor 12″. The response method may also be any of the above methodsbut not limited to these methods. The callback and the response list ismeant to be illustrative, while not limiting the complete options ofcallback and response methods. Other possible callback methods areincluded within the true scope of this invention.

In alternative embodiment, authorized transactor 12″ may request thatcallback be initiated only upon transaction values above a pre-selectedthreshold. Or alternatively, different callback methods may be selectedfor different threshold values, e.g., no callback for transactions under$100, SMS for transactions between $100 and $500, and a phone call fortransactions over $500. Thus, based on the needs of each authorizedtransactor 12″, the validation process may be limited to significanttransactions only. Authorized transactor 12″ may be enabled to specifyother criteria for validation process initiation. For example,authorized transactor 12″ may choose to ask for a verification on anytransaction of a specific type of service.

The response from authorized transactor 12″ to validation server 20 maybe in one or more of several forms, such as: a voice response, with anoptional voice recognition system to validate a password, oralternatively, a speaker verification system; a signature response via afax transmission, optionally using signature verification software; ane-mail response, with an optional alphanumeric password; a link into anew web page, optionally provided via an e-mail and with a requirementfor a password; an instant message response, with an optionalalphanumeric password; an SMS response, with an optional alphanumericpassword; a special application that may reside on a computer or PDAheld by the originator—the response would be specific to thisapplication and may prompt the user for a password in an alphanumericform or a pen based forum or even a finger print forum; a mail responseand a personal validation (last two although slow, may be preferred bysome non-technical users or may be used in special cases). A form may beprovided with directions on how to respond in each method. The responselisting is meant to be illustrative, while not limiting the completeoptions of response methods. Other possible response methods areincluded within the true scope of this invention.

In yet further alternative embodiments, the authorized transactor 12″may specify several methods for the validation process; each method willbe used in turn if the previous methods fail to get a response. Eachmethod may be associated with a password.

The password may be in one or more of several forms, depending on thedevice used for the response: DTMF digits when a phone is used for theresponse, alphanumeric if a computerized device is used, voiced passwordusing a phone, real signature sent by a fax or a pen based PDA, or abiomatric method such as finger prints when a capturing device isavailable. This password listing is meant to be illustrative, while notlimiting possible options. Other possible passwords are included withinthe true scope of this invention.

Validation Server 20 and Callback Processor 22

Reference is now made to FIG. 3, a block diagram illustrating a modelvalidation server 20 and a callback processor 20. It is noted that FIG.3 is only a partial illustration of system 10. For ease ofunderstanding, refer also to FIG. 1B.

Validation server 20 may comprise an input/output (I/O) device 24, acomputer processing unit (CPU) 26, a memory 28, and validation processmanagement software 30. In some embodiments, password database 18 may beheld in memory 28, while in other embodiments transaction approvalauthority 16 may hold password database 18.

Callback processor 22 may comprise an I/O 32, a CPU 34 and callbackinterface unit 36 and callback management software 38. Managementsoftware 38 manages the processes within callback processor 22.

While not being shown, validation server 20 and callback processor 22comprise the elements needed for implementation of hardware andsoftware, such as an operating system and a bus. As is known to thoseskilled in the art, system 10 may be provided either as a hard wireddevice or as a computer program to be implemented on a hardwired device.

In one preferred embodiment, validation server 20, via I/O 24, receivesa request for validation from transaction approval authority 16. I/O 24may be a network interface card or any other device capable ofinterface. CPU 26 receives the request from I/O 24. CPU 26 may managethe validation process and implement validation software 30. CPU 26 mayconsult with memory 28, receiving therefrom the pre-selected callbackand response method associated with the requested authorized transactor12″.

CPU 26 activates callback processor 22 with instructions that are sentthrough the interface between them, optionally through I/O unit 32. CPU26 may also activate a second callback processor 22, the duty of whichis to receive the response from authorized transactor 12″.

I/O device 32 of callback processor 22 receives the instruction fromvalidation server 20, which is then transferred to CPU 34. Theinstruction transferred to CPU 34 contains information relating to thecallback or response.

CPU 34 activates callback interface 36, which connects with theappropriate communication provider, for eventual contact with authorizedtransactor 12″. For example, if the pre-selected callback method is ane-mail, callback interface 36 may be a mail sender that sends an e-mailthrough an Internet provider. Alternatively, if the pre-selected methodis an SMS message to the personal digital assistant (PDA), callbackinterface 36 may be an SMS sender that sends an SMS through a cellulartelephony provider.

In some embodiments, if contact can not be made with authorizedtransactor 12″ using the initial pre-selected callback method, callbackprocessor 22 notifies validation server 20, which may then initiatealternative forms of callback.

Upon receipt of the message from callback processor 22, authorizedtransactor 12″ responds to the same or other callback processor 22according to the chosen response method. Interface 36 receives theresponse, and sends it on to validation server 20 using I/O 32. CPU 26processes the response, validating it with a lookup table held in memory28. It is noted that a lookup table may be alternatively replaced with adatabase or any other method of holding information. It is additionallynoted that the validation information may alternatively be held bytransaction approval authority 16 and transferred to validation server20 upon need.

CPU 26, via I/O 24, sends a message to transaction approval authority16. The message may be a recommendation to approve, or not approve, thetransaction. Alternatively, the message may request further information,or notify of a failure to contact authorized transactor 12″. The messagemay also contain further information related to either the transactionor authorized transactor 12″.

While the present specification has been described with reference to oneor more specific embodiments, it is not meant to be limiting. It isnoted that while product provider 14 and transaction approval 16authority are noted herein as separate entities, in other embodimentsthey may be the same entity. Additionally, while the present inventiondescribes validation server 20 and password database 18 as separateentities, in other embodiments they may be the same entity.

It is appreciated that one or more of the steps of any of the methodsdescribed herein may be omitted or carried out in a different order fromthat shown, without departing from the true scope of the invention.

While the methods and apparatus disclosed herein may have been describedwith reference to specific computer hardware or software, it isappreciated that the methods and apparatus described herein may bereadily implemented in computer hardware or software using conventionaltechniques.

While the present invention has been described with reference to one ormore specific embodiments, the description is intended to beillustrative of the invention as a whole and is not to be construed aslimiting the invention to the embodiments shown. It is appreciated thatvarious modifications may occur to those skilled in the art that, whilenot specifically shown herein, are nevertheless within the true scope ofthe invention.

1. A method for processing a transaction, the method comprising thesteps of: receiving validation requests; in response to said validationrequests, automatically initiating, according to pre-selected authorizedtransactor information, one or more callbacks to said authorizedtransactor; and validating, according to said pre-selected authorizedtransactor information, one or responses from said authorizedtransactor, said responses in reply to said callbacks.
 2. The method ofclaim 1, and further comprising the step of: providing a validationresponse relating to approval of said validation request, saidvalidation response in response to said validation requests.
 3. Themethod of claim 1, wherein said step of validating comprises the stepof: confirming a password associated with said authorized transactor,wherein said pre-selected authorized transactor information comprisessaid password.
 4. A transaction processing system comprising: a callbackprocessor automatically initiating, in response to one or morevalidation instructions and according to pre-selected authorizedtransactor information, one or more callbacks to said authorizedtransactor; and a validation server for validating, according to saidpre-selected authorized transactor information, one or more responsesfrom said authorized transactor, said responses in reply to saidcallbacks.
 5. The system of claim 4, wherein said callback processorcomprises: an input/output (I/O) device for receiving said instructionsand said responses; a callback interface for sending said callbacks; anda computer processing unit (CPU) for activating and for managing theprocesses of said callback processor using callback management software.6. The system of claim 4, wherein said validation server comprises: ainput/output (I/O) device for receiving one or more requests forvalidation and for sending said instructions to said callback processor;a memory for holding said pre-selected transaction information; and acomputer processing unit (CPU) for implementing validation processesmanagement.
 7. The system of claim 6, wherein said validation processesmanagement is deployed by a computer software product.
 8. The system ofclaim 6, wherein said pre-selected authorized transactor informationcomprises a password.
 9. The system of claim 4, wherein said validationserver comprises said callback processor.
 10. A computer programembodied on a computer-readable medium, the computer program comprising:a first segment operative to receive validation requests; a secondsegment, operative to automatically initiate, in response to saidvalidation requests, according to pre-selected authorized transactorinformation associated with an authorized transactor, one or morecallbacks to said authorized transactor; and a third segment operativeto validate, according to said pre-selected authorized transactorinformation, one or responses from said authorized transactor, saidresponses in reply to said callbacks.
 11. The program of claim 10, andfurther comprising: a fourth segment operative to provide a validationresponse relating to approval of said validation request, saidvalidation response in response to said validation requests.
 12. Theprogram of claim 10, and further comprising: a fifth segment operativeto confirm a password associated with said authorized transactor,wherein said pre-selected authorized transactor information comprisessaid password.
 13. A method of processing a transaction, said methodcomprising the step of: deploying a computer program embodied on acomputer-readable medium, the computer program comprising: a firstsegment operative to receive validation requests; a second segment,operative to automatically initiate, in response to said validationrequests, according to pre-selected authorized transactor information,one or more callbacks to said authorized transactor; and a third segmentoperative to validate, according to said pre-selected authorizedtransactor information, one or responses from said authorizedtransactor, said responses in reply to said callbacks.
 14. The method ofclaim 13, wherein said step of deploying further comprises the step ofdeploying a fourth segment operative to provide a validation responserelating to approval of said validation request.
 15. The method of claim13, wherein said step of deploying further comprises the step ofdeploying a fifth segment operative to confirm a password associatedwith said authorized transactor, wherein said pre-selected transactioninformation comprises said password.